1. Field of the Invention
The present invention relates to manufacturing processes, and more particularly to monitoring batch manufacturing.
2. Background
Manufacturing of batch (or bulk) products is common today. Some products within the batch product category are milk, juice, oil, cosmetics, pharmaceuticals and other similar products. The term “batch” means non-discrete. A car in this sense is a discrete product, while milk during manufacturing/processing is a batch product.
Monitoring batch product manufacturing is complex and the need to monitor batch processing is compelling today. It is important to have the ability to trace batch products to specific raw material sources and manufacturing units. This is particularly critical if a particular batch of product (for example, milk or any other product) has been contaminated by a terrorist organization. This requires the manufacturing plant to act immediately and with accuracy so that contaminated product can be re-called quickly and efficiently with minimum waste to the businesses that are engaged in batch product manufacturing. Failure to perform this can result in health hazards and/or waste.
Conventional batch product manufacturing plants and techniques do not provide a system and/or methodology to track batch products so that various lots can be tracked. Most batch manufacturing plants can be modeled after the ISA S88.01 industry standard (referred to herein as the S88 standard), published by The International Society of Measurement & Control (ISA) and incorporated herein by reference in its entirety. S88 defines a model and methodology for manufacturing plants. A manufacturing unit in a manufacturing plant is a single logical device and a S88 phase is an activity that is performed on a particular unit in a manufacturing process.
An example of a prior art system 100 is provided in FIG. 1A. System 100 has a receiving bay 101 that is used to receive bulk raw products. For example, in a milk bottling/processing plant, the receiving bay will receive raw milk from various farms/trucks. Various trucks from different farms unload milk into bay 101 and the milk is commingled. From bay 101, raw milk is transferred to a storage unit 102 (may also be referred to “raw silo”). More than one storage unit 102 may be used to store the raw milk.
Milk from various storage units 102 is sent to Separator(s) 103. Thereafter, skimmed milk 104 is sent to pasteurizing unit(s) 107 for pasteurizing the milk. Raw cream 105 is sent to cream storage unit(s) 106. Raw cream is also sent from cream storage unit(s) 106 to pasteurizing unit(s) 107. Pasteurized milk is then transferred to storage unit(s) 108 and then moved to filing stations 109.
Currently, programmable logic controllers (“PLCs”) are used in the various units described above to collect data. An example of one such PLC is 1756 ControlLogix™ from RockWell Automation™. Typically, these PLCs collect data based on time intervals. The data is captured by an OPC server, which is an industry standard for polling data from PLCs and is incorporated herein by reference in its entirety. An example of this architecture is shown in FIG. 3A and is discussed below.
If milk gets contaminated and has to be recalled, system 100 cannot trace a particular lot to a defined source. System 100, when used to recall product will be inaccurate and potentially result in waste.
Conventional systems have drawbacks, including the following:
Current data collection is performed with a graphical user interface (“GUI”). Data collection schedules are often hard coded and are not flexible. Data is collected based on timestamps at pre-defined intervals. Often correlating data to real events occurs after the fact, which affects the accuracy of the analysis. Therefore, there is a need for a system/methodology that allows efficient and accurate correlation between collected data and real time events in manufacturing plants.
Typically, data is collected by PLCs and analyzed by application programs. The collected data has two states (or attributes), for example, data is either known or unknown to the application. When data is being polled from a PLC, a specific value can trigger an event/process, for example, storing information in a database. The process can be triggered multiple times under certain conditions, for example:
A data value that is being polled for the value of 1 is initially 0.
When this value becomes 1, it triggers a process.
The data value becomes unknown due to a problem, for example, a communication problem with the PLC.
Data value becomes known again after the problem is fixed and is still 1.
Every time this happens, the process is triggered incorrectly.
Therefore, there is a need for defining data states such that processes are not triggered incorrectly resulting in waste and inefficiency.
Another drawback with current process monitoring techniques is that PLCs are designed and sold by plural manufacturers. This requires the PLC data collection system to customize OPC servers (or any other interface) for every make and model. FIG. 3A shows an example of this architecture. PLC1 and PLC2 are coupled to OPC server 1, PLC 3 and PLC4 are coupled to OPC server 2 and PLC5 and PLC6 are coupled to OPC server 3. Application programs 1, 2 and 3 are coupled to OPC servers 1, 2 and 3 to analyze and parse the PLC collected data. This system becomes very tedious and expensive in a manufacturing plant that uses PLCs from different vendors. Therefore there is a need to develop a system that is flexible and efficient in handling PLC data from plural vendors.